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ABSTRACT 


A look at HF channel conditions and historic Amateur radio practice 
reveals weaknesses in current packet radio link level protocol 
implementations. In line with the author's views of how protocols 
should work (see Level 8 Protocols elsewhere in these Proceedings), 
some features of ALink90, an experimental link-level protocol, are 
described. 


CHANNEL CONDITIONS FOR AMATEUR PACKET ACTIVITY 

Amateur rf paths for data have a number of departures from the ideal. 
The characteristics noted below are aggravated on HF, but they are 
generally true on VHF channels as well. 


Low Speed / Narrow Bandwidth, 


Most Amateur packet activity occurs at 300 bps on HF channels, 1200 
bps on VHF/UHF channels. 


Shared Channel 


The Amateur service denies the luxury of individual users "owning" 
specific frequencies. Except for coordinated repeaters, everyone has 
an equal right to available frequencies. As ae result, frequencies 
must be shared. Packet is one of the few digital modes which allows 


such sharing. 

Hidden Transmitters 

Along with shared channels, most Amateur packet activity occurs on 
channels with hidden transmitters. This means that not all_e stations 
can hear all other’ stations. This may be due to range, shadowing, 
differing power levels or other reasons. 


Noise 


Amateur frequencies are typically noisy. Weak signals, combined with 
multipath distortion, are common on HF as well as VHF/UHF. 


Half-Duplex 


Amateur gear is almost exclusively half-duplex. Amateur operations 
are almost exclusively half-duplex. This simply means that you cannot 
normally receive at the same time you are transmitting. 
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HISTORIC AMATEUR OPERATING PATTERNS 


Radio is often used for roundtable discussions. Voice and CW nets 
with designated control stations and a variable number of check-ins is 
another common Amateur use. Of course, Amateurs also engage in one- 
on-one conversations by radio. Many times, an Amateur station does 


not previously know the station contacted (calling CQ). 


Telephones are used for one-on-one conversations. The calling party 
deliberately dials the called party. The called party is usually 
known in advance of the call to the calling party. 


As a result of these differences, telephone-based protocols may not be 
optimum for radio. usage. 


AX.25 LINK LEVEL PROTOCOL LIMITATIONS 


The AX.25 Level Two protocols (versions 1, 2.0 and 2.1) provide 
reliable information transfer between two stations when signal levels 
are good and there are no hidden terminals. 


A number of the deficiencies in versions 1 and 2.0 have been addressed 
in version 2.1. 


Still, point-to-multi-point communications are not provided for. 
Retries are handled by pinging the other station before resending the 
data. Multiple frames are used for lengthy transmissions, adding 
overhead. There is no automatic methodology specified for tailoring 
the various protocol timers and variables to the RF path in _ use, 
placing a large technical burden on often naive _ users. And the 
protocol specifications are lengthy and _ complex. 


Recognizing that AX.25 Level Two is not a panacea for all situations, 


the ARRL and others are actively working on developing a suite of 
protocols to handle various media (HF, satellites, etc.). 


ALink90 PROTOCOL FEATURES 


ALink90 seeks to resolve many of the deficiencies of current Amateur 
HF protocols. ALink90 provides the following features: 


Protocol Timers Gated with DCD 
The only timers used are for retry. If the channel is occupied, you 
shouldn't transmit. Your re-transmit timer shouldn't-= run, either! 


This requires the TNC modem to provide a data carrier detect (DCD) 
Signal only when it senses other stations' signals. 


Unconnected Mode Operation 


ALink90 supports acknowledgments, but not connections, Connected mode 
operation is possible, however, when running higher level protocols. 
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No Digipeaters 


A link protocol should only operate between stations in the same RF 
domain. Range extension should be handled as a Level 3 _ function. 
ALink90 is concerned with the task of getting chunks of information 
from one station to another (or others) in a single hop. 


ARQ Operation 


ALink90 doesn't incorporate forward error correction techniques. 
Instead, it relies on the receiving station(s) to send explicit 
acknowledgment (ACK) upon receipt of uncorrupted data. 


HDLC Format 


ALink90 would be useless if it couldn't run on existing hardware. 
Thus, it uses standard HDLC techniques for operation. 


Prioritized Ack 


If a data transmission occurs, the destination station(s) will send an 
ACK immediately. The sending station will then have the best 
opportunity to determine if the frame just sent was received. 


Stop-and-Wait 


ALink90 allows only a single frame in flight between stations. 
Another frame will not be sent until the current one is ACKed. This 
simplifies the protocol, minimizing memory and processor requirements. 


The station sending data will respond to a received ACK by either 
sending more data (if more data is presently available) or an ACK-ACK. 


Data is allowed to flow only one way at a time in ALink90. Thus, the 
ACK-ACK is a way of automatically turning the link around in a _ similar 
fashion to manually sending +?_in AMTOR. 


P-Persistence for Channel Access 


Since the channel must support multiple QSOs, p-persistence is used to 


socially balance the users. If a station has data to send and detects 
the channel is clear, the station won't necessarily send the data 
immediately. This allows other stations that may be waiting to have a 


chance at accessing the channel to send their data. 


Persistence Value Dynamically Adjusted 


The number of users on a channel varies. For example, at 7 P.M. ona 
Sunday night, the local VHF channel may be very busy, but become very 
quiet by 3 A.M. ALink90 dynamically adjusts the probability of 


accessing the channel based on measured channel occupancy. 
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Frame Length Dynamically Adjusted 


Although ALink90 allows only one frame in flight between stations, it 
tailors the maximum allowed length of the frame based on the path 
between the stations (not on channel occupancy). A fast-attack, slow- 
decay algorithm is used to adjust the maximum allowed frame size. In 
order to support reducing the length of a frame already sent but not 
acknowledged, automatic fragmentation is included in the down-sizing 
of the frame length. Fragmentation is a part of the retry process, so 
no data need be lost while the protocol adjusts to path conditions. 


Multi-Way Connects 


ALink90 allows as many as nine (9) stations to participate in a multi- 
way QSO. If the paths are good, data need only be sent once for 
guaranteed delivery to all other’ stations. If conditions deteriorate, 
or if one or more links are marginal, data may have to be re-sent. A 
slotted acknowledgment scheme minimizes the channel bandwidth needed 
to support multi-way QSOs. 


Existing schemes for packet roundtables either assume all stations can 
copy all others at all times and go "UNPROTO" mode (utopian 


conditions), or the data is sent to each individual station and 
acknowledged (extremely wasteful of channel bandwidth). 


Callsign is Address 


Callsigns of up to 15 characters are allowed. There are no 
restrictions on the characters that may be used in the callsign field. 


Multiple "Connects" Allowed 


There is no restriction on implementations to allow a given station to 


participate in more than one QSO at a time. This is a function of a 
higher level than the _ link. However, ALink90 still requires that a 
station may only send data to one station (or group in the case of a 
multi-way QSO) during any data transmission sequence, This is for 


social balance -~ no station should be allowed to "hog" a _ channel. 
STRUCTURE OF A FRAME 

The byte order of the various fields sent in a frame is: 

SYNC FLAG HASH LID SRC DEST CNTL FID FRAG NID DATA FCS FLAG 

The meaning of each field will now be explained. 

SYNC 

Preframe sync consists of a stream of zeroes during this’ station's 
transmit keyup delay time. These synchronizing zeroes will speed 


lockup of the receiving station(s) demodulator clock recovery 
circuits. 
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FLAG 


The flag is the standard HDLC value of 7E hex, with no bit stuffing. 
This flag marks the beginning of a frame. 


HASH 


For point-to-point links, this is an 8-bit value corresponding to the 
encoded callsign of the destination station. For multi-point QSOs, 
the value is set to FF hex to exploit the use of hardware HDLC 
controllers with address recognition capabilities. 


The algorithm used is a simple 8-bit summation of the callsign field, 
excluding -length byte: 


{SUM(n) = sum(n-1) + byte(n)] 


LID 


The Link ID is used to identify the link level protocol in use. A 
value of 02H is initially being used to identify ALink90. 


SRC 

This is the callsign of the sending station. It is prefixed with an 
eight-bit character count which serves as ae pointer to the next 
address in the queue. While 15 characters are allowed in this field, 


it may be as short as a single character (plus character-count). 


Character encoding may be arbitrary. It is recommended that ASCII 
encoding be used, and that upper case characters be used, along with 
numerals and the "/" character. 


There is no bit shifting. Further, the callsign field is simply an 
address list. There are no command or response bits, no digipeater 
bits and no other control bits buried in it. 


DEST 

This is a list of callsigns of the destination station(s). It may be 
a minimum of one (1) callsign field and a maximum of eight (8) 
callsign fields. The callsigns are encoded as in SRC, above. 

CNTL 


The control byte is used to control the information flow on the data 
link. It presently allows two types of data frames and four types of 
supervisory frames. 


Data frames are used to frames convey information to the other 
station(s). These frames may or may not require an acknowledgment. 


Supervisory frames indicate data frame acknowledgments, acknow- 
ledgments to data frame acknowledgments, error recovery and TNC busy. 
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A simplified control field structure allows simple bit masking or 
shifting instructions to be used in software to determine frame types 
and actions required. 


FID 


The Frame ID is an eight-bit value which changes when a frame is being 
sent that is different than the last. one. It remains constant 
throughout a frame fragmentation/de-fragmentation procedure. 


There is no requirement that FIDsS be consecutive, only that an FID be 
different than the last one originated from this station in a 


particular QSO. 
FRAG 


The fragmentation field indicates the size of the frame length allowed 
and where in the possible frame space of 4096 bytes the present 
fragment fits. This field is a single byte, and is always sent. 


NID 


The Network ID byte is used to indicate the next higher level of 
protocol being used, if any. If none is used, a value to be 
negotiated with the ARRL Digital Committee will be sent. Initial 
experiments use a value of FO hex to indicate no higher layer. 


DATA 


This is a field of an arbitrary number of bytes. The only limitation 
is that it must not exceed the currently allowed maximum frame length. 


This is a 16-bit CRC based on ISO 3309. 


FLAG 


This flag is identical to the one which marks the beginning of a 
frame. This one marks the end of the frame. The station transmitter 
should shut down immediately after sending this flag. Trailing bits 
after this flag will be ignored by the receiving station(s). 


Since there is only one frame allowed per transmission, a single flag 
byte cannot mark the end of one frame the the beginning of a following 
frame. 


CHANNEL ADJUSTMENT 


ALink90 incorporates a number of special features to dynamically 
"tune" its operation to channel conditions. It carefully differenti- 
ates between channel occupancy and channel quality. These features, 
and the algorithms to implement them, are described below. 
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DYNAMIC FRAME SIZING 
Overview 


A QSO is initiated with a frame length allowed of 128 bytes. Fragmen— 
tation allows reducing this size without losing data being transferred 
between stations. 


The maximum frame length allowed is 32 bytes at the low end, 4096 
bytes at the high end. 


If the channel can support longer frames, it is allowed to do so. If 
the path becomes’ noisy, frame length collapses rapidly and 
fragmentation occurs quickly for this frame. 


Algorithm 


The permitted frame length increases and collapses according to the 
following rules: 


NOTE: Nlo is the retry count for the station originating (sending) 
the current frame. 


1) Start with frame length = 128 bytes. This is a reasonable frame 
length to start with under typical 1989 operating conditions. 


2) If data flows to other station(s) with no more than two frames 
retried and no frame retried more than once during the last eight 
frames, and if at least two of the last eight frames were longer 
than 50% of the allowed frame length, double the allowed frame 
length. 


This means that if the channel quality is good and there is 
sufficient data in the queue to warrant attempting it, cautiously 
increase the frame length. 


3) Repeat step 2 until allowed frame length = 4096, 

4) If retry for a given frame is two (Nlo = 2), divide frame length 
by four (but the value must not be less than 32), fragment this 
frame and try again. Do not clear Nilo. 


If retries are beginning to build up, aggressively back off the 
maximum allowed frame length. 


5) If Nlo = 4, divide allowed frame length by four (but the value 
must not be less than 32), refragment this frame and try again. 


Do not clear Nlo. 


6) If Nlo = 6, set allowed frame length to 32, refragment this frame 
and try again. Do not clear Nlo. 
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FRAGMENTATION 
Overview 


If the frame being sent is too long for the path to support, it must 
be fragmented into smaller frames at the sending end, and properly 
sequenced at the receiving end. In some cases, the frame must be re- 
constructed into a single, larger frame at the receiving end for 
proper operation of a higher-level protocol. 


ALink90 provides both a frame ID and a fragmentation byte to allow 
this to happen automatically and transparently. 


Algorithm and Control Field 


The fragmentation byte is encoded to show the level of fragmentation 
(maximum frame length versus 4096 bytes allowed by the protocol) and 
the location within in the 4096 byte possible frame that the fragment 
fills. This encoding technique allows dynamic frame sizing to occur 
during the transfer of the fragmented frame. 


The fragmentation byte is encoded as follows: 


Bit Frame Length 
7654 3210 

Onnn nnnonn 32 

10nn onoonann 64 

110n nnnonn 128 
1110 nnovrann 256 

1111 OoOnnn 512 

1111 10nn 1024 
11141 110n 2048 

11141 114310 4096 

Ted. 2 1111 Frame not fragmented 


The “walking 0" is used as demarcation of the size information (high 
order ones) and the pointer to the start of the current frame's 
information field within the 4096 byte possible frame (values of hn). 


The receiving station places the data field received in the 4096 byte 


frame being reconstructed at the location specified by n. This is 
done even if this field has already been received at a different size 
level for this frame ID. This method allows dynamic frame sizing to 


occur even while sending a fragmented frame. 

DYNAMIC PROTOCOL TIMERS 

Overview 

The only protocol timer used in ALink90 is Tl, the retry timer. There 


are two Tls =- Tlo for the _originator (sender) of the current data 
stream and Tld for the destination (recipient) of the data stream. 
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The timers are gated with DCD from the _ modem. Therefore, the TNC 
won't be counting time when other stations are using the channel. 
This automatically "backs-off" the rate of introduction of data to the 
channel by this station when the channel load increases. This is not 
enough, however, to maximize the efficiency of the channel. 


ALink90 assumes there are other stations using the channel. Further, 
it assumes that any particular station will not be able to hear all 
the other users of the channel, but that one (or more) of the stations 
in the current QSO may hear some of these "hidden transmitters." 


The protocol makes a further assumption that the hidden stations, with 
whom the rf domain of the present QSO may overlap, find their paths to 
be about as good as this station finds its path(s). 


Algorithm 


Tlo allows at least two other stations to be hidden and send data 
frames with frame lengths as long as this station allows. Therefore, 


Tlo = bit_time * 8 * (frame _length _allowed t overhead) * 2 
A maximum length overhead is 9 call signs of up to 15 characters plus 


9 byte counts, a two-byte FCS, two flag bytes, an LID byte, an NID 
byte, an FID byte, a fragmentation byte, a control byte and a hashing 


byte, for a total of 54 bytes. A typical overhead byte count for a 
point-to-point QSO between two stations with 6 byte callsigns is 24 
bytes. Current AX.25 usage is 20 bytes under the same circumstances. 
Hidden transmitters may disrupt an incoming ACK. Since ACKs will 


usually take much less time to send than data, Tld is set to a value 
of Tlo/4. This means that, on average, four (4) ACKs will have to be 
missed by the originating station before it re-sends the data (and 
increments its retry counter). 


Since the fragmentation byte of the received frame tells the receiving 
station the frame _length allowed by the sender, it is a simple matter 
for the receiver to set its Tld to the appropriate value. 


Finally, since a prioritized ACK scheme is implemented, the sending 
station will usually not have to wait to receive an ACK. Thus, when 
conditions are good, data will flow rapidly. 


DYNAMIC P-—PERSISTENCE SELECTION 
Overview 


Channel access probability should be based solely on channel occupancy 
by other users, It should not be based on channel propagation 
efficiency (noise) or other path-related concerns. 


Current approaches to addressing congested channels cause the retry 
timer (T1) to rapidly increase in value, reducing offered load to the 
channel, if an ACK isn't received when expected. This has’ the 
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undesirable effect of reducing load to a channel that is not occupied, 
but merely noisy. Still, it is the correct approach if round-trip 
time is the only criterion upon which offered load is based, 


ALink90 gates Tl with DCD, so Tl is effectively backed off as a result 
of channel occupancy, not channel quality. Prioritized ACK has’ the 
effect of usually telling the originating station immediately if the 
frame got through. 


Dynamic updating of the persistence parameter, p, based on channel 
loading can help reduce retries based on channel congestion. 


If there are no other users on the channel, the persistence value 


selected should approach 0.9. A value of 1.0 would either prohibit 
other users from accessing the channel, or ensure collisions and 
retries if they attempt to. If there are many other users on the 
channel, the persistence value selected should approach 0.1. If it 


needs to be less than this, there are too many QSOS on this channel! 


Algorithm 

The probability of accessing the channel to send data is expressed as 
Pp. If p = 1, the TNC will send if the channel is clear. If p = 0, 
the TNC will never. send. ALink90 allows p to range from 0.125 to 


0.875, based on channel occupancy. 


A 7-minute moving average, updated every 25.5 seconds, is maintained 
of detected channel use. This is done by gating a 100 mSec_ sampling 
counter with DCD. P is then (one minus the measured channel activi- 
ty) » limited at the busy case to 0.125 and limited to 0.875 if the 
channel appears’ unused. 


MULTI-WAY STREAMS 

Overview 

ALink90 allows multi-point conferencing, or roundtable discussion, for 
up to nine stations without individually sending the data to each 
station. This multi-way system is especially suitable for group QSOs, 


small nets (DX alerts and so forth) and for inter-BBS forwarding of 
bulletins and other targeted information dissemination. 


Implementation and Algorithm 


The address field can contain up to nine stations. The first field is 
the sending station. The second through ninth are the destination 
stations, 


A slotted, prioritized ACK scheme is employed, with additional ACKs 
sent as needed based on expiry of each station's Tld timer. 


The prioritized ACKs are sent by the destination stations in their 
order of appearance in the address field. The algorithm used is: 
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1) Delay (Position in address field - 1) * (TXD t ACKTIME) 
2) Send ACK, start Tld. 


Where: TXD is xmtr keyup time, defaulted to 50 mSec. 
ACKTIME is 35 * 8 * bit _time. 


Subsequent ACKS, based on expiry of Tld, follow normal channel access 
procedures. 


Other stations on the channel, upon decoding any information frame, 
will wait this amount of time before attempting to access the channel. 
Thus, even if a station can't hear all the ACKs, it will refrain from 
colliding with any of the ACKs (assuming it hears the data frame). 
Further, if a station hears any decodable frame, it will wait at least 
one ACK time before attempting channel access. 


CONCLUSION 


A straightforward, adaptive link-level protocol tailored for the 
Amateur packet radio environment has been outlined. Although not 
compatible with current versions of AX.25, a number of the ideas 
presented here could be incorporated in other link level protocols, 
perhaps even in AX.25 version 3.0. 


ALink90 is not intended to supplant AX.25. Rather, it is an 
experimental protocol for further investigation into automating link- 
level and media-access decisions. The goal is optimizing the 
efficiency of limited bandwidth, multi-user packet radio channels. 
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